In the following we describe 3 strategies: each is more complex than the previous.

passive: weak cartell - hard wired fix price table
minimal responsiveness: if margin is not guaranteed, the peer is not forwarded to. 

reactive - respond to downstream price increase with exploring alternative peers. If there is no alternative it raises the price. If downstream peers drop the price, it follows suit.

proactive: respond to 


\subsection{Passive strategy \statusorange}\label{sec:pricing-retrieval}
The following strategy is a basic way on how nodes *can* use the protocol described above. The strategy intends to be as easy as possible to implement, while balbalbala

\subsubsection{Margin}
A nodes price for a `ChunkDeliveryRequest` is always at least his desired `margin` + the price of the cheapest upstream peer. 

\subsubsection{Filling the priceInformationRegistry}
Initially, nodes only know the price for serving content from the most proximate bin (price == `margin`). When this node gets his first request for serving content that is one proximity order away from the border of his most proximate bin, he will first of all check that the price for this request is more than his margin. If this is the case, he will forward the `RetrieveRequest` with a price of 0 (since the state is not initialized yet). If the upstream peer in the appropriate bin did not change his price, this peer will get back a `NewPrice` message, where the price equals the `margin` of the downstream peer. If the original price is at least 2x the `margin`, the node can forward the request with a price of `margin` (and pocket the other marin himself). From this point onwards, the `state` is initialized for one peer and one proximity. Subsequent `RetrieveRequests` to this peer will be send with a `price` of `margin`. Chunks which are further away will have a higher price. The peer will quickly learn about this via this iterative process. If all peers apply the same `margin`, the price of a `ChunkDelivery` equals the proximity order between the requestor and the chunk times the `margin`. If a peer get's a request for a chunk with a price that is less than his `margin` + the price of the cheapest upstream peer in that bin, the request is not forwarded, but immediately answered by a `NewPrice` message with a price equal to the `margin` + the price of the cheapest upstream peer in that bin.

\subsubsection{Reacting to price differences}
In a network where no peer ever charges a `margin` different than the default margin, `NewPrice` messages will be only send to peers who have not fully initialized their `state` and, given equal proximity between the requested chunk and the peer in a particular bin, a node does not have a preferred supplier of a chunk based on the price. If any peer in the network would change his price, however, a preference based on price will emerge:

For any chunk request:
- Select the bin to forward the request to
- Select the peers who are closest to the chunk in terms of PO
- Select the peer with the lowest price
- Do a round-robin load balancing if there are multiple peers with the same price

From this, we can conclude that if a peer lowers his price, he is expected to receive more `RetrieveRequests` and if a peer increases his price, he is expected to receive fewer `RetrieveRequests`. A node who is connected to an upstream peer with a lower price may decide to lower his price for this distance as well in order to receive more requests.

\subsubsection{Notifying about price changes}
It is in the interest of the network, that when there is a price change this gets propagated as soon as possible to the relevant parties. A price change can be initiated by a change of `margin`, or by a change of the price from upstream peers. In both cases, a peer might decide not to notify other peers about the decrease in price--the only thing which changes is that it will accept `RetrieveRequests` with a lower price than before. Without notifying the downstream peers, however, a node might not get the expected amount of additional clients directly, as the downstream peers might never propose a lower price than before. For this reason, we propose that nodes pro-actively send `NewPrice` messages to his peers, essentially requesting them to update their `priceInformationRegistry`. In the case of pro-active `NewPrice` messages, the `chunkReference` may be synthetic, meaning it does not have to respond to an actual chunk; all that is important is that peers update their `priceInformationRegistry`.

\textbf{Overpriced bins}
Since the price of a node depends on the price of his upstream peers, it might happen that by change, all his upstream peer-connections in a certain bin are populated by expensive peers—effectively making the node itself to be too expensive as well for his downstream peers. To solve this issue, we propose to do statistical analysis: if a node has sensible prices across his bins, it is expected that he receives an equal amount of requests for all his bins. If a node receives statistically significantly less requests for one bin compared to his other bins, he marks the supposedly overpriced peers as non-functional and the hive protocol should kick in to suggest new peer connections. 

\textbf{Reacting to demand increases/decreases}

A node that decreases its price such that he is the cheapest, is expected to get much more traffic. Without an adequate response to an increase in traffic, a node might be forced to go offline as D

\subsubsection{Configuration options}
The following configuration options will be added. 

\begin{verbatim}

| name | unit | default |
| -------- | -------- | -------- |
| `margin`     | base currency of chequebook     | 0     |
| `period`      | duration in seconds    | 300     |
| `maximum_upstream_bandwidth`      | bandwidth usage in bytes per `period`     | TODO     |
|`high_water_mark`    | percentage: (upstream bandwidth used / `period`) / (`maximum_upstream_bandwidth`)     | 80%     |
| `low_water_mark`    | percentage: (upstream bandwidth used / `period`) / (`maximum_upstream_bandwidth`)      | 20%     |
| `margin_change`    | percentage    | 1%     |

\end{verbatim}

See below for how these variables are used.

\subsection{Behavior of a node \statusred}
1) Given a particular \lstinline{`chunkReference`}, a node chooses to send the $`ChunkRequestMessage`$, usually, to the peer with the lowest price of all peers in that bin.
2) If a `newPrice` message is returned from a `chunkRequestMessage`, the node updates the `priceInformationRegistry` and sends the `chunkRequestMessage` again, choosing a peer on the basis of the updated `priceInformationRegistry`. 
4) When a peer requests a certain `ChunkRequestMessage` and does not have the `chunkContent` in its local storage, it forwards the `chunkRequestMessage` (see 1) with a price equal to the `chunkRequestMessage` it received minus his `margin`.
5) A node keeps track of his `bandWidth\_usage` (\lstinline{(upstream bandwidth used / `period`) / (`maximum\_upstream\_bandwidth`)})
6) Whenever `bandWidth\_usage` > `high\_water\_mark`, the `margin` will be (1+`margin\_change`) * `margin`
7) Whenever `bandWidth\_usage` < `low\_water\_mark`, the `margin` will be (1-`margin\_change`) * `margin`. `margin\_change` indicates the 
8) Whenever a node can get a `chunk` for a cheaper price than requested by a `ChunkRequestMessage` (upstream peers changed prices, amount of hops are less than the average request for the same distance), he answers with a `ChunkDeliveryMessage`, which will be priced based on the `ChunkRequestMessage`. 
9) Whenever a node expects to be able to deliver long-term lower prices than currently known by his peers, he sends a `NewPrice` message to his peers. 
